-
-
Notifications
You must be signed in to change notification settings - Fork 287
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: #217 - onboarding screenshot generation. #1529
feat: #217 - onboarding screenshot generation. #1529
Conversation
New files: * `app_test.dart`: Onboarding screenshots. * `screenshot_driver.dart`: Screenshot driver. Impacted files: * `analytics_helper.dart`: added a special case for screenshot init. * `main.dart`: refactored for screenshots, and more specifically moved init code to be run before calling the app. * `next_button.dart`: added a `Key` for test/screenshots * `Podfile.lock`: wtf * `pubspec.lock`: impacted by `pubspec.yaml` * `pubspec.yaml`: added integration_test and flutter_driver to dev_dependencies.
Impacted files: * `pubspec.lock`: impacted by `pubspec.yaml`. * `pubspec.yaml`: upgraded the version numbers.
That's awesome @monsieurtanuki |
That's what you have to run:
As is, that generates the screenshot files with hard-coded names in a new
|
also device size / models (especially for iOS) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heyyy thanks a lot @monsieurtanuki, automated screenshots ate definitely great. I actually have a stale integration tests branch it's a great opportunity to add further testing together with the screenshots. The majority looks good but please have a look at my comments.
Future<void> _initScreenshot( | ||
final IntegrationTestWidgetsFlutterBinding binding, | ||
) async { | ||
if ((!kIsWeb) && Platform.isAndroid) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can't be Web when it's android or am I missing something
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, but I explicitly say that I handle the kIsWeb
case - which wouldn't be obvious without that additional test. Or it would be a comment: I prefer code to comment.
if (!_screenshots) { | ||
await _userPreferences.init(_productPreferences); | ||
} | ||
AnalyticsHelper.initMatomo(context, _screenshots); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can just put it in the if statement above
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No I can't: I do things in AnalyticsHelper.initMatomo(context, _screenshots);
.
packages/smooth_app/lib/main.dart
Outdated
if (!_screenshots) { | ||
FlutterNativeSplash.remove(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a comment why we what it looks like never remove the splash screen
await app.main(screenshots: true); | ||
await tester.pumpAndSettle(); | ||
|
||
sleep(const Duration(seconds: 30)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think pumpAndSettle
already takes care of waiting
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure of anything anymore. Especially when there's async load: ok the pumpAndSettle
will tell you that the display is refreshed, but not that the data was loaded async'ly in order to refresh the display.
if (!_screenshots) { | ||
await _userPreferences.init(_productPreferences); | ||
} | ||
AnalyticsHelper.initMatomo(context, _screenshots); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need _screenshots as argument as it's a global variable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it is: it's private.
static void initMatomo(final BuildContext context) { | ||
static void initMatomo( | ||
final BuildContext context, | ||
final bool screenshotMode, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need this parameter as it's a global value
final bool screenshotMode, | ||
) { | ||
if (screenshotMode) { | ||
setCrashReports(false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about putting the same logic in initSentry
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not that I particulary care about Matomo rather than Sentry; it's just that initMatomo
froze the app in screenshot mode. And I'm sort of forced to call initMatomo
so that the next matomo calls don't crash.
In screenshot mode I don't even call initSentry
.
|
Impacted files: * `main.dart`: added a comment. * `screenshot_driver.dart`: removed a "forbidden" `print` statement.
Codecov Report
@@ Coverage Diff @@
## develop #1529 +/- ##
==========================================
- Coverage 8.90% 8.89% -0.01%
==========================================
Files 161 161
Lines 6581 6596 +15
==========================================
+ Hits 586 587 +1
- Misses 5995 6009 +14
Continue to review full report at Codecov.
|
@monsieurtanuki this whole analytics stuff looks a bit confusing to me, we call the initialization but return before the real call and first set the analytics to what is saved in the preferences then overwrite it when in screenshot mode. Instead of putting in the mock preferences, but let's not block it on this we can always improve that part later. |
Thank you @M123-dev! |
New files:
app_test.dart
: Onboarding screenshot generation.screenshot_driver.dart
: Screenshot driver.Impacted files:
analytics_helper.dart
: added a special case for screenshot init.main.dart
: refactored for screenshots, and more specifically moved init code to be run before calling the app.next_button.dart
: added aKey
for test/screenshotsPodfile.lock
: wtfpubspec.lock
: impacted bypubspec.yaml
pubspec.yaml
: addedintegration_test
andflutter_driver
todev_dependencies
.What
FutureBuilder
management by the test framework.app_test.dart
(how to star the screenshots) andscreenshot_driver.dart
(how to make that work in iOS)Screenshot
Part of